經過 26 天的探索，我們從抽象思維出發，一步步穿越基礎建設的各個層面。從「設計思維」到「技術落地」，每個階段都像是在堆疊一個平台的結構體。來到第 27 天，也象徵著這段旅程即將進入尾聲。

接下來的篇章，我們不再只聚焦單一技術，而是以「資料平台」為核心，思考這些元件如何彼此銜接，共同構築一個能處理、同步與儲存資料的中樞系統。

為了實現這個目標，今天我們將進行回顧與盤點，並開始著手搭建實際專案，在建構過程中探索資源、進行技術選型，並驗證整體架構是否能順利運作。這不再是單純的 PoC，而是一個能夠逐步延伸、具有實戰價值的工程基底。

回顧與盤點

回顧前六個階段，我們已完成了資料平台的主要技術地圖：

1️⃣ 工程思維與抽象（Day 1–4）
從語意、案例與設計平衡出發，討論「抽象」如何幫助工程師提煉問題，建立具備彈性的架構視角。

2️⃣ Helm 實戰（Day 5–9）
以 values.yaml 為核心，學習 template 設計與版本策略，觀察 Bitnami Chart 的模組化與一致性設計。

3️⃣ GitLab CI/CD（Day 10–13）
探討 Runner、部署策略與自動化管線設計，讓部署與版本控制能自然融入團隊工作流。

4️⃣ Log、Kafka 與系統底層（Day 14–18）
深入事件流的運作邏輯，理解 Kafka 如何以 Log 為核心支撐資料一致性與多訂閱場景。

5️⃣ Kubernetes 實務（Day 19–22）
從 annotation、CRD 到外部 API 互動，體會 Kubernetes 的抽象層與可擴充性設計。

6️⃣ Terraform 與基礎建設自動化（Day 23–26）
回到 IaC 的根本，探討模組化、參數治理與多層次架構，確立基礎設施的一致性與可維運性。

這六大區塊不僅是技術清單，更構成了資料平台的基礎，它們將引導我們將抽象目標逐步轉化為可執行的工程實踐。

元件盤點

在整合階段，我們的核心任務是把前面各個技術模組串聯成一個具備完整資料流的專案架構。
這個專案的重點不在於驗證可行性，而在於建立能實際部署、測試與維運的資料平台雛形。
以下是主要元件的分類與功能盤點：

• 資料來源（Source）：

  • MySQL —— 作為測試資料的起點，模擬業務系統的交易與行為資料，使用 Kubernetes Deployment 或 StatefulSet 管理。

• 中間件（Middleware）：

  • Kafka —— 承擔事件流中樞角色，實作 Log 為核心的資料流，支撐資料一致性與多訂閱場景，由 Strimzi Operator 管理 Cluster。

• 資料流與處理（Streaming & Processing）：

  • Kafka Connect —— 將資料從來源導入 Kafka Topic，再同步到 Sink，實現簡單的資料管線，透過 Deployment 管理。

• 服務管理（Service Management）：

  • Strimzi Operator —— 自動化管理 Kafka Cluster Lifecycle，降低操作複雜度。
  • Schema Registry —— 維護資料結構一致性，支撐版本演進與管線治理。

• 基礎設置（Infrastructure Setup）：

  • Docker Desktop Kubernetes —— 提供本地 Kubernetes 環境，承載 MySQL、Kafka 與 Connect，模擬生產環境。
  • Kubernetes Namespace、ServiceAccount —— 建立權限與隔離邏輯，確保多環境治理。

• 部署與自動化（CI/CD）：

  • GitLab.com + Runner（shell executor）—— 將部署流程自動化，支援本地測試與資料流驗證，形成可重現的操作流程。

這些元件將在後續篇章中逐步被串接，形成一個可操作、可觀察的資料平台專案，讓讀者理解每一步設計背後的工程邏輯。

專案架構目標

目標：
建立一個能在本地 Kubernetes 環境運作的完整資料流專案，從資料來源到下游儲存，清楚展示資料平台的結構與服務間的互動關係。

核心理念：

1. 結構化搭建：
   透過 Helm、Terraform 與 CI/CD 流程，展示如何從零開始構築可維運的基礎架構。

2. 模組化設計：
   每個元件（MySQL、Kafka、Connect）皆以獨立模組存在，方便擴充與替換。

3. 自動化與重現性：
   使用 GitLab CI/CD 管理部署與初始化，確保每次搭建都能被自動化重現。

4. 從實作理解抽象：
   不只是驗證資料是否能流動，而是理解整個資料平台如何協同運作。

專案結構

project/
├── terraform/                # 管理 Kubernetes Namespace 與其他基礎資源
├── helm/
│   ├── kafka/                # Kafka Helm Chart 配置
│   └── connect/              # Kafka Connect Helm Chart 配置
├── mysql/
│   ├── init.sql              # 測試資料初始化腳本
│   └── deployment.yaml       # MySQL Deployment 與 Service
├── sink/
│   ├── deployment.yaml       # Sink Deployment (MySQL 或 FileSink)
│   └── service.yaml          # Sink Service
├── gitlab-ci/
│   └── .gitlab-ci.yml        # GitLab CI/CD Pipeline
└── README.md                 # 專案說明與操作流程

這個結構以工程角度出發，強調明確分工與擴充彈性。未來不論要改用其他資料源（PostgreSQL、ElasticSearch）或新增新的 Sink，都能輕鬆延伸。

架構流向圖

[MySQL Source]               # 資料來源
      │
      ▼
[Kafka Connect (Source)]     # 從 MySQL 抓取資料至 Kafka Topic
      │
      ▼
[Kafka Broker / Topic]       # 資料事件流中樞
      │
      ▼
[Kafka Connect (Sink)]       # 將資料同步至下游
      │
      ▼
[Sink (MySQL/FileSink)]      # 結果存放區

--- Deployment & Control ---
[GitLab CI/CD]               # 控制部署與驗證流程
   ├─> 啟動 Helm Chart（Kafka + Connect）
   ├─> 初始化 MySQL 測試資料
   └─> 驗證整體架構運作

與 PoC 驗證不同，這裡的重點在於系統搭建與可維運性，確保每個元件能被正確啟動、監控並形成資料流閉環。

小結

經過前 26 天的探索與實務分享，我們已經完整梳理出資料平台的技術脈絡：從抽象思維與設計哲學，到 Helm、CI/CD、Kafka、Kubernetes 與 Terraform 的實際落地，每個環節都為後續的整合與搭建奠定基礎。

今天，我們正式進入專案整合與搭建階段，重新聚焦於「如何構築一個能真實運作的資料平台」。
這個階段的重點不再是概念驗證，而是以工程實作為核心，逐步建立能部署、能維運、能驗證的完整系統。

• 盤點並明確每個元件在整體架構中的定位與責任，建立清晰的組成藍圖。
• 制定專案結構，規劃資料從來源（MySQL）經 Kafka 與 Connect 到下游儲存的完整流向。
• 確立 GitLab CI/CD 為整體控制中樞，支援自動化部署與一鍵驗證流程。

透過這個過程，我們將不只是理解「技術怎麼運作」，而是學會「如何搭建出能穩定運作的資料平台」。
這正是從抽象概念走向實際工程落地的關鍵一步。

接下來的篇章，我們將開始逐步建構專案架構，探索可用資源與技術選型，並最終完成一個可在本地 Kubernetes 環境中真實運作的資料平台。

謝謝各位的閱讀，我們明天見！